Working Group meeting
Date: 06/09/2022
Participants: Cecile Guasch, Natalie Muric, Csongor Nyulas, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discuss notice metadata
-
Plan to generate a new version with notice metadate included.
-
Publish the normalisation scheme for standard form mappings.
-
Diagram containing notice metadata:
At-voc:implementation-regulation
-
This needs to be changed.
-
The relation for regulation implementation should go from epo:Notice to at-voc:legal-basis.
-
If we include the regulations, we have to change the name “legal-basis” of the controlled vocabulary.
-
Changed epo:hasImplementationRegulation to epo:isBasedOnImplementationRegulation wit the following definition: “Indicates under which regulation a notice is created.
WG Acceptance 06/09/2022” -
How to signal the difference between SF notices and eForms notices?
-
The implementation regulation should help in this, but might not be enough.
-
Working Group meeting
Date: 23/08/2022
Participants: Cecile Guasch, Natalie Muric, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Standard forms mappings F21 & F22
-
F21
-
II.1.6.1 II.1.6.1.1 II.1.6.1.2 II.1.6.1.3
-
II.1.6.2
-
II.1.6.3
-
V.2.4.1 (It is the same as II.2.6)
-
-
Discussion
-
II.1.6) Information about lots
-
epo:ProcedureSubmissionTerm is created:
-
Subclass of epo:ProcedureSpecificTerm
-
-
-
Renaming epo:SubmissionTerm to epo:LotSubmissionTerm and the definition modified appropriately
-
Adding new attribute epo:isSubmissionForAllLotsAllowed in class epo:ProcedureSubmissionTerm for subsection “Tenders may be submitted for all lots” with the following definition: “Indicates whether tenders may be submitted for all Lots.
Additional information:
This field is used to complement the SubmissionTerms (which are at the Lot level) for the Procedure level which is covered by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms)
WG approval 23/08/2022“
-
Renaming attribute epo:hasLotSubmissionLimit to epo:hasMaximumLotSubmissionAllowed
-
Adding boolean attribute epo:isOneLotOnlyAllowed with the following definition: “Indicates whether tenders may be submitted for only one Lot.
Additional information:
This field is used to complement the SubmissionTerms (which are at the Lot level) for the Procedure level which is covered by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).
WG approval 23/08/2022”
-
Moved epo:hasMaximumNumberOfLotsToBeAwarded attribute in epo:ProcedureTerm
-
Decided to delete class epo:ProcedureSubmissionTerm and moved attributes to epo:ProcedureTerm
-
For the subsection “The contracting authority reserves the right to award contracts combining the following lots or groups of lots:” a new string attribute should be created on the epo:ProcedureTerm, epo:hasLotAwardCombination, with the following definition: “The contracting authority reserves the right to award contracts combining lots or groups of lots.
Additional Information:
This property contains information about the Lots concerned.
This property is required by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).
WG approval 23/08/2022”
-
V.2.4.1 (It is the same as II.2.6)
-
The value in section II is used only when we have a call for competition.
-
The value in section V is used in all other cases.
-
They do not appear at the same time
-
In case we have different values between contract notice and contract award notice we need to provide another predicate.
-
Created the predicate epo:hasRestatedEstimatedValue. “A forecast of the value of the procurement before competition, which is repeated in the contract award notice.
-
Additional Information:
This property should be equivalent to the epo:hasEstimatedValue. It is created, however because the existent data model two different fields (with the same conceptual meaning) and therefore the values may differ.
This property is required by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).
WG Approval 23/08/2022”
-
In all Contract Awarded Notices, in section V, we should use epo:hasRestatedEstimatedValue and in section II, we should use epo:hasEstimatedValue
-
In the next meeting should be discussed which metadata should be included as part of the content.
Working Group meeting
Date: 16/08/2022
Participants: Peter Borresen, Cecile Guasch, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
eOrdering discussion
-
Present the proposed eOrdering model.
-
Between epo:Order and epo:Item should be a reification. There are properties that are dependent on the item. (e.g. delivery conditions).
-
Introducing epo:OrderLine. In version 2.0.2 OrderLine existed.
-
The constraint on epo-ord:containsOrderLine should be kept open in order to not lose valid use cases.
-
There is a framework contract with a set of items that have been agreed upon. This contract can be used to create a system. The buyer starts a process asking the supplier to provide an optimal configuration.
-
The request might be a vague order line which gets refined in the process.
-
For an order line to be correct it must either provide an item description or specify an item.
-
There are things that are described but they do not exist in a catalogue.
-
Some attributes from epo-cat:CatalogueItem are common and they are moved to epo:Item.
-
To be discussed in a future eCatalogue meeting.
eFulfilment discussion
-
A proposed UML model for despatch advice logistics is presented.
-
Providing use cases as github issues are preferred.
-
There are no requirements for primary and secondary parties.
-
The definitions of the entities should be provided as well.
-
The proposed UML diagrams should be used. === Roles in Despatch advice
-
The scope is to align the concepts from PEPPOL ordering and despatch advice with what there is already in ePO. ==== epo:Deliveree
-
Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.
-
Renaming epo-ord:Deliveree to epo-ord:Consignee and keep the definition from Deliveree because the term Consignee is a more used term in PEPPOL. (inform Pieter as well)
epo:Originator
-
Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.
-
The name Beneficiary gives more information.
-
Need → Initiation of Need fulfilment request → Provision of the need fulfilment means.
-
Changing the definition for epo-ord:Originator
-
When the Buyer creates a framework contract, it does not catch the real Originator.
-
Creating epo:Beneficiary with the following definition: “The role of an agent that consumes the goods and on whose behalf makes the purchase.
Additional Information:
The Beneficiary is the end-user and is often the Consignee and the Originator.
”
-
Adding as a requirement that the Buyer can also originate the order.
-
epo-ord:Originator should be moved to epo:Originator in the core module. To be discussed in the future meeting. == Working Group meeting
Date: 09/08/2022
Participants: Natalie Muric, Csongor Nyulas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Discuss Concession concept in the context of standard form mappings. === Discussion
-
Added new class epo:ConcessionEstimate with the following particularities:
-
The attribute epo:hasCalculationMethod was moved to epo:ConcessionEstimate.
-
The predicate epo:foreseesConcession has target class epo:Tender and source class epo:ConcessionEstimate.
-
The predicates epo:hasEstimatedUserConcessionRevenue and epo:hasEstimatedBuyerConcessionRevenue have target class epo:ConcessionEstimate and source class epo:MonetaryValue.
-
-
Added predicate epo:definesConcessionDuration between epo:ContractTerm and epo:Duration.
-
Added predicate epo:definesConcessionPeriod between epo:ContractTerm and epo:Duration.
Working Group meeting
Date: 02/08/2022
Participants: Natalie Muric, Csongor Nyulas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
eNotice
-
Separate the Notice systematisation (Notice module) from the Notice content (NoticeContent module)
-
In the Notice module we have instances created from the values of CV like in the example below:
-
We are constraining a class to a specific value of a property (Directive 23 in the image above)
-
There is a controlled list for all notice subtypes in eForms.
-
Restricting cardinalities for epo:hasNoticeType
-
The namespace prefix to be used should be epo-not:
-
The notice package from ePO core should be moved to the Notice module.
-
Check all attributes from epo:Document and decide what namespace should be used (epo:hasPublicationDate) and if they should be moved at the Notice level.
-
For the moment what is in the Document class should stay there and decide what can be moved in the future.
-
The package notice classes seem ok. Check and validate this package.
-
Creating pmc:at-voc:notice-type with a comment that this value is not part of the notice type controlled vocabulary yet.
-
If it is a D24, then it is a Prior Information Notice.
-
If it is a D25, then it is a Periodic Indicative Notice. == Working Group meeting
Date: 26/07/2022
Participants: Paloma Arillo, Cecile Guasch, Giorgia Lodi
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
eCatalogue missing definitions
Added new definitions for the following:
-
epo-cat:Certifier “A role of an agent that assesses the conformance of an Item to a set of requirements and grants the certificate as a proof of conformance.
WG approval 26/07/2022”
-
epo-cat:CertificationLabel “Concept that stands for a set of norms, expectations, standards and policies.
Additional Information:
Such standards may relate to social, ethical and quality etc.
WG approval 26/07/2022”
-
epo-cat:ItemDescription “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.
WG approval 26/07/2022”
-
epo-cat:ItemCertificate “”
-
epo-cat:hasPricePercentage “The factor relative to the price charged in addition.
WG approval 26/07/2022”
-
epo-cat:hasCertificationNumber “The unique identifier of the certificate.
WG approval 26/07/2022”
-
epo-cat:hasAttributeType “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.
WG approval 26/07/2022”
-
epo-cat:hasFixedAmount “The predetermined monetary value charged in addition to the price.
WG approval 26/07/2022”
-
Added epo-cat:hasReferenceURI attribute on the class epo-cat:CertificationLabel with the following definition: “A reference to where the label specification (norms, expectations, standards and policies) can be found.
WG approval 26/07/2022”
-
epo:hasValidityPeriod “The property indicating when the ItemCertificate is in force.
WG approval 26/07/2022”
-
epo-cat:issuedByCertifier “Relation indicating the Certifier responsible for providing the ItemCertificate.
Additional Information:
Certifier is a role played by an organisation.
WG approval 26/07/2022”
-
epo-cat:attestedByLabel “Relation indicating the conformance subject represented by a CertificationLabel.
WG approval 26/07/2022”
-
epo-cat:hasCertification “The property providing the proof of conformance.
WG approval 26/07/2022”
-
epo-cat:hasBaseQuantity should be mandatory, so the cardinality was set to 1.
-
epo-cat: hasLeadTime changed to epo-cat:hasExpectedDeliveryTime with the following definition: _“The expected amount of time between the order and delivery of an item. _
WG approval 26/07/2022”
Working Group meeting
Date: 19/07/2022
Participants: Paloma Arillo, Cecile Guasch
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Close eCatalogue GH issue 343
-
Start discussing eOrdering
Discussion
Environmental/Social labels for items
-
There is a collection of requirements and there are several labels. Each of these associations provide certification schemes.
-
It is not good to look at that only from the label perspective.
-
There is a connection between the requirement set and the procurement criteria, and some of the labels can serve as a fulfilment as a procurement criteria.
-
CCCEV might be used in these circumstances. Might complement these labels.
-
Some subtypes of criteria can constitute a requirement for a particular label.
-
Directive 2014/24 mentions the following:
-
(75) Contracting authorities that wish to purchase works, supplies or services with specific environmental, social or other characteristics should be able to refer to particular labels, such as the European Eco-label, (multi-)national eco-labels or any other label provided that the requirements for the label are linked to the subject-matter of the contract, such as the description of the product and its presentation, including packaging requirements. It is furthermore essential that those requirements are drawn up and adopted on the basis of objectively verifiable criteria, using a procedure in which stakeholders, such as government bodies, consumers, manufacturers, distributors and environmental organisations, can participate, and that the label is accessible and available to all interested parties. It should be clarified that stakeholders could be public or private bodies, businesses or any sort of non-governmental organisation[…].
-
(23) ‘label’ means any document, certificate or attestation confirming that the works, products, services, processes or procedures in question meet certain requirements;
-
(24) ‘label requirements’ means the requirements to be met by the works, products, services, processes or procedures in question in order to obtain the label concerned.
-
-
CCCEV should be revised and compared with the actual modelling of Environmental/Social labels.
-
Information Concept (CCCEV) seems to be a Label concept, based on the definition.
-
To the currently proposed model of Item labels we should add concepts from CCCEV as presented in the diagram below:
-
Certification is on the item.
-
The eCatalogue module developed is only for the exchange of information between catalogue providers and receivers.
-
Any additional requirement for other use cases should be added as a github issue.
-
The GitHub ticket can now be closed.
Working Group meeting
Date: 12/07/2022
Participants: Georgia Lodi, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
Status Information
-
We made considerable changes between the beta release and the final release. This discussion will have an impact on the model.
-
Having a status seems reasonable, but if we commit to a status we also need to commit to a process, to the status of phases, etc.
-
Then why not add the epo:isTerminated boolean at the level of Competition notice or DPS?
-
Are Procurement Relaunch BT-634 and PIN Competition Termination BT-756 mutually exclusive? Probably not. We can not see that from the eForms mapping.
-
We should choose the minimum for this release.
-
Should we add a boolean at the procurement object level?
-
But in the future we need to refer to that procurement object.
-
Relaunch and recurrence information are about the rules of succession of procedure. The difference is that the recurrence information is announced at the beginning of the procedure, and the relaunch is in the end.
-
We don’t need to distinguish if it is a termination of the competition or DPS. We can infer this based on the previous notice reference. (see standard form F03, section IV.2)
-
We need to create a proper systematisation of techniques and classes.
Decision taken:
-
Change StatusInformation to ProcurementProcessInformation
-
Add specific booleans for Competition and DPS
-
Create a link to a previous notice
-
This should be refactored in a future release.
Working Group meeting
Date: 05/07/2022
Participants: Georgia Lodi, Natalie Muric, Giovanni Paolo Sellitto, Reka Markovich
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
VAT ontology
-
Discuss feedback on ePO version 3.0.0
-
GitHub issue 357
-
CV buyer legal type
-
Joint venture and Organisation Group === Discussion
-
VAT ontology
-
This is a new specific ontology project coming from the University of Luxembourg.
-
Judgement cases will be used for this project.
-
The model can emerge from the already existing data. Some requirements that are important for the modelling come from the data.
-
This can be linked to eOrdering and eCatalogue ( see GH 355)
Feedback on ePO version 3.0.0
Gihub issue 357
-
The attribute epo:isCompetitionTermination is already deleted in version 3.0.0 beta.
-
Now we have two predicates from epo:CompetitionTerminationInformation:
-
epo:concernsProcedureCompetitionTermination
-
epo:concernsLotCompetitionTermination
-
-
Renaming the above predicates to:
-
epo:concernsProcedure
-
epo:concernsLot
-
-
We need to create a class that hold both information about relaunch and termination (Procurement Relaunch BT-634)
-
The Dynamic Purchase System (DPS) should link to Lot and Procedure (epo:DynamicPurchaseSystemTechnique).
-
A procedure should use a technique (from the current standard forms), also a lot (from eForms).
-
The technique is merely a controlled list.
-
At the moment ePO provides the following path: epo:Lot epo:usesTechnique epo:Technique.
-
This aspect should be addressed with the current standard forms mappings.
-
BT-119 DPS Termination is the same concept as lot/procedure competition termination.
-
A DPS legally has no end date until it is terminated.
-
It is not the DPS technique that should have the termination attribute, but the DPS. One option is to create a DPS class and an EAuction class, and move all attributes from technique classes to those newly created classes.
-
Also, a technique should not have a validity period (epo:Technique epo:hasValidityPeriod epo:Period)
-
In 2.0.1 the attribute epo:hasMaximumParticipantsNumber was on epo:FrameworkAgreementTerm.
-
Is the period redundant?
-
The usage for eAuction or DPS should not be at the technique level.
-
We can have a framework agreement that uses EAuction.
-
The dps-usage codelist should probably be associated with the notice class, because it is about the notice.
-
If we say that a procedure uses a DPS technique, it means that the specific procedure is a DPS.
Action Points
-
Revise techniques diagram:
-
Procedure and Lot should use a technique.
-
Remove attributes from the technique classes.
-
The at-voc:usage codelist should not be at the EAuction technique level.
-
Also see where at-voc:dps-usage should be.
-
Create classes for DPS and EAuction.
-
Get rid of validity period
-
They belong to instances and not techniques
-
-
-
Revise CompetitionTerminationInformation and RelaunchInformation modelling.
-
Procedure should have a period.
Working Group meeting
Date: 21/06/2022
Participants: Georgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Work on eCatalogue Github issues
-
Discuss VAT Ontology === Discussion
-
The work needed for eCatalogue module development is in the Github issue 339. ==== VAT Ontology
-
Start from the written Law and provide the conceptual mapping
-
To serve as a conceptual map for judges and lawyers
-
Lightweight ontology, no axiomatic underpinning
-
Instance texts:
-
judgement cases to be annotated ( ~ few thousands cases),
-
identify concepts in the texts
-
Core Legal Ontology is something to look into
-
Working Group meeting
Date: 14/06/2022
Participants: Georgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Discuss ePO 3.0.0 beta release === Discussion
-
Buyer responsibilities
-
TED-SWS notices transformation pipeline:
-
Present the conceptual mappings
-
RML mappings
-
SHACL validation report
-
Action Points
-
Develop competency questions and sparql queries based on ePO 3.0.0 == Working Group meeting
Date: 07/06/2022
Participants: Georgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
ePO 3.0.0. beta release
-
Preparing an worksheet with the new definitions for classes and attributes === Discussion
Discuss https://github.com/OP-TED/ePO/issues/349
-
The request is to change the name of predicate epo:involvesBuyer to a more representative naming, like epo:isResponsabilityOfBuyer.
-
Also, the boolean attribute epo:isResponsibleForProcedure won’t help in the case of knowing which is the procedure that the specific buyer is responsible for.
Indeed if we used a boolean attribute, it allowed for the possibility to have multiple buyers involved, none of which were responsible for the procedure. Using two relations, however, enables us to enforce that at least one buyer MUST be responsible for the procedure.
Discuss https://github.com/OP-TED/ePO/issues/341
-
Investigating how the ECLASS classification system describes items in a structured manner.
-
We should treat this as an additional custom description of an item.
Discuss https://github.com/OP-TED/ePO/issues/340
-
The relation dct:requires replaces epo-ecat:hasRequirementItem.
-
The relation dct:hasPart replaces epo-ecat:hasComponent.
Discuss https://github.com/OP-TED/ePO/issues/324
A Catalogue is provided by a CatalogueProvider, which is playedBy an Organisation, which has an Address.
Working Group meeting
Date: 24/05/2022
Participants: Cecile Guasch, Natalie Muric, Georgia Lodi
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Collect feedback on the refactored model
-
Present the Glossary
-
ConcessionContract added
-
Discuss the new definitions === Discussion
-
Checking alignment to Core Vocabularies (namespaces and definitions)
-
Check for Business class in Core Organisation (?)
-
Discussion on CoreCriterion and ESPD: https://github.com/OP-TED/ESPD-EDM/tree/v3.0.1/conceptual-model === Action points
-
Publish html Glossary for review
-
Check alignment to Core Vocabularies (namespaces and definitions)
-
Update attributes names to any core classes, including cpv:Person
-
-
Revise the Criterion module
-
Check according to eForms
-
Check CCCEV
-
epo:hasPersonalSituationCondition attribute is an instance of cccev:InformationRequirement (it may be removed ???) but it has to be mapped from StandardForms
-
Separate threshold and weight : weight is in criterion and threshold is on constraint
-
-
Import Core vocabularies into ePO ontology
-
CPV
-
CPOV
-
Create a configurable import specifications for model2owl (Dragos) == Working Group meeting
-
-
Date: 17/05/2022
Participants: Cecile Guasch, Natalie Muric, Georgia Lodi
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Collect feedback on the refactored model === Discussion
-
Presenting the document from CPSV: comparison between the CPSV-AP approach and the ePO approach.
-
A Concession Contract is a new specific type of Contract.
-
Adding this as a new class in the ePO model, epo:ConcessionContract.
-
The definition can be taken from the Directive 2014/23/EU ==== Overview diagrams for the ePO model
-
-
Overview
-
Phase views
-
Monetary values
-
Aspect views for:
-
Procurement objects
-
Techniques
-
Strategic procurement
-
Criterion
-
Terms
-
Agents
-
Location
-
Roles
-
Documents
-
Contextual information
-
Notice description
-
Data types
-
-
The Glossary is under development and will be available in the HTML format.
-
Planning to publish 3.0.0 beta by July 2022
-
Revise, collect and implement the feedback
-
Publish 3.0.0 by mid-July 2022
-
We might not have all the definitions in place yet.
-
Proposing to put all epo classes in a flat list when publishing the model.
-
The Lot is not subject to the Contract Term; it foresees the Contract Term.
-
Contract terms are foreseen in the Lot and in the Contract they are used.
Action points
-
The Glossary is under development and will be available in the HTML format.
-
We might not have all the definitions in place yet.
-
Propose definitions and review them in a future working group meeting.
-
Propose definitions for new classes
-
Propose definitions for new attributes
-
Propose definitions for relations
-
Prepare an inventory worksheet for the WG to easily discuss
-
-
The ePO model should be able to directly use CCCEV.
-
Revise the model with Natalie
-
-
Check alignment to Core (namespace, definitions)
-
Follow the rule of thumb: reuse if identical meaning and extend if the meaning is slightly changed (i.e. new attributes or relations)
-
Check:
-
Location
-
Person
-
Organisation
-
CCCEV
-
…
-
-
-
Create a new epo:Term subclass, epo:ContractSpecificTerm which is a generalisation for epo:ContractTerm.
-
Create a new epo:ConcessionContract.
-
Copy from CPSV-AP V3.0 == Working Group meeting
-
Date: 10/05/2022
Participants: Cecile Guasch, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Collect feedback on the refactored model === Discussion
-
The upper level of the chain can not be accessed and there might have been relationships at the upper level (how the Tender is involved in the submission process).
-
Creating a Glossary for procuring it at the european level.
-
Takes time to familiarise with the model
Publication: asserts inventory
-
EAP model
-
OWL core, OWL restrictions, SHACL shapes,
-
HTML generated by EA with diagrams
-
Glossary of terms (classes, properties, attributes)
-
Documentation explaining where the assets are and how to navigate them ==== Publication plan:
-
Revise in the WG narrower
-
Collect feedback
-
Implement or plan for the future
-
-
Revise in the WG broader
-
Collect feedback
-
Implement or plan for the future
-
-
Publish ==== Feedback
-
Need Tenderer and Submission view
-
DOLCE in Core vocabularies might be inconsistent
-
The objects over time view is valuable ==== User experience
-
Main objects over time
-
Unfold phases
-
Unpack what is relevant for each phase ( which objects/types? ) === Action points
-
Prepare and publish a glossary of classes and properties/attributes
-
An HTML page sorted with an index (A, B, C)
-
-
Find a way to make the model easily presentable
-
Creating easily to navigate diagrams
-
-
Contextual information hierarchies/relation diagrams needs reworking
-
Dangling objects?
-
What keeps them together?
-
Award
-
-
Add connections between roles and objects
-
Tenderer tender
-
Lot/Procedure buyer
-
-
Make sure that the roles have the context clearly indicated
-
Which objects may be valid contexts for each role
-
-
Make a diagram for
-
Submission
-
Award
-
Contract
-
-
Finally put all the classes in a flat list
-
Hide links to objects that are not part of the core
-
E.g. upper level
-
E.g. diagrams from other modules
-
-
Model the Award Decision
-
An AwardDecision can capture outcomes of awarding multiple Lots
-
Rename the LotAwardOutcome into “LotAwardDecision”
-
-
The AwardDecision is not a document it is a ProcurementObject
-
A Procedure can have multiple AwardDecisions
-
An AwardDecision has identifier
-
A Tender and an AwardDecisions are at the same level
-
-
Show how terms are associated to a Procedure, Lot, Contract
-
Presenting the FIBO model with agent-in-role pattern.
-
epo:Contract - epo:LotAwardDecision: rename the relation from epo:includesLotAwardOutcome into epo:isResultOfLotAwardDecision
-
epo:ContractTerm should be connected to the epo:Contract and not the epo:Lot (?)
-
Shall we consider the epo:TemplateContract / epo:DraftContract == Working Group meeting
-
Date: 12/04/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Diagram explanation for Object Description design pattern: http://ontologydesignpatterns.org/wiki/Submissions:DescriptionAndSituation
-
Diagram explanation for AgentInRole - SocialReality design pattern:
-
the role of an agent also captures the description of that agent in a particular event
-
Discussion
-
How is the refactored version reflected in the owl model?
-
We should stick to the domain ontology and not include the upper level ontology layer. This should be used only to guide us into ePO modelling.
-
Descriptions appear at the moment; they are not phase specific. They can be updated in other phases.
-
Provide a temporal view of the procurement objects.
-
Consider renaming LotCompletionInformation since ePO does not provide any Completion class.
-
epo:Stipulation is the superclass that unifies all the term classes.
-
This might be a good class to keep in the core to have the epo:isSubjectToTerm predicate linked directly to it.
-
Rename it into epo:Term with the following definition: “A Governing condition or stipulation.”
-
-
Conceptualise the document as something that has an AccessURL.
-
For example, a Tender has all the data and also can have an AccessURL where the document can be downloaded.
-
The epo:Document is under epo:InformationRealization which is the file.
-
Is the perspective to describe the document or to describe the object of the document?
Decisions:
-
Agreeing to keep separate the ePO core elements from the notice elements.
-
Getting the model refactored within the next two weeks, including ePO conceptual model UML, OWL model and SHACL shapes and restrictions.
-
Publish on the TED documentation website where all the files can be found.
-
Deadline to provide the files in the github: 29th of April
-
Send email to the ontology working group with the link to the documentation on the TED website.
-
Next meeting should be on the 10th of May, in order to provide a week for review within the working group.
-
Mention in the documentation all the alignments to DUL and the context organised notice content (to be delivered after this deadline).
Working Group meeting
Date: 05/04/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Show WG how the Diagrams Values are currently transposed from the sandbox into the ePO model:
-
Show the Information classes
-
Show the AwardResult situation
-
Show completion values
-
-
In eForms (Rethink Tender/TenderLot, Tender as something englobing a group of lots)
-
Tender is perLot or group of lot, which is not necessarily the same as a LotGroup;
-
A contract is per Tender
-
-
Show proposed Review model.
-
We can look into Roles.
-
(Situations shall still be revised first)
Discussion
Roles overview
Proposed model is to use Role as a class that is played by an Agent.
We have three types of Roles:
-
Procurement role is directly involved in the procurement process;
-
Procurement subrole is secondary to the procurement process;
-
Related role is not involved in the procurement process.
Proposed renaming epo:Role in epo:AgentInRole:
Discussing an instance diagram example for a submission phase:
We just need to have the situation where organisation is already implied for the role of Tenderer.
In this case we will have all the URIs of the Organisation + all the URIs for roles + all the URIs for the submission.
Working Group meeting
Date: 22/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Show WG how the Diagrams Values are currently transposed from the sandbox into the ePO model:
-
Show the Information classes
-
Show the AwardResult situation
-
-
In eForms (Rethink Tender/TenderLot, Tender as something englobing a group of lots)
-
Tender is perLot or group of lot, which is not necessarily the same as a LotGroup;
-
A contract is per Tender
-
-
We can look into Roles
-
(Situations shall still be revised first)
Discussion
Tender and Values
-
There are multiple types of values:
-
Award related values
-
Submission related values
-
Estimated related values
-
-
The BTs should not be mentioned in the ePO definitions. Proposing to remove these in another place. Maybe as notes in the diagrams.
-
The value-type document should be saved somewhere in the github.
Diagram for estimation related values:
Diagram for submission related values:
-
A tender is usually composed of documents, one of them being a financial offer. The document that is the financial offer contains the financial offer value.
-
Should we remove the source of the epo:hasFinancialOffer relation from epo:Tender to epo:FinancialOffer?
-
When modelling the ESPD response we will need the epo:FinancialOffer class.
-
The goal is to make sure that ePO covers at best the eForms and standard Forms.
-
The ESPD should be a module itself and eOffer as well.
-
Moving epo:TechnicalOffer and epo:FinancialOffer to eOffer module.
-
Moving epo:ESPDResponse and epo:ESPDRequest to ESPD module.
-
The StatisticalInformation classes should remain in the ePO module.
Diagram for award related values:
The LotAwardDecision is the Result.
In the end, the value is associated with the Lot.
An Award Decision can not have a value.
Decision
-
In the ePO module we aim at covering the eForms and standardForms.
-
The BDTI AP should be modified since we renamed the ContractAwardNotice class into ResultNotice == Working Group meeting
Date: 15/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Continue discussing the List of values:
-
BT-161
-
BT-118
-
BT-156
-
BT-709
-
BT-660
-
BT-710
-
BT-711
-
-
*Decide LotGroup model: *final version of Lot/LotGroup/SubmissionTerm/Tender
-
Tender is always submitted on a Lot (never on a LotGroup)
-
Tender may be subject to grouping by a LotGroup (at most one)
-
-
Consider SubmissionResult situation
-
Consider AwardResult situation
-
framework agreement is not interchangeable with award results even if some values may be the same.
-
-
What is the proper way to assign __phase dependent information to Lot_ / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place._
-
-
Discuss Roles and Situations.
Discussion
Decide LotGroup model
(proposed model)
This proposed model is in agreement with the WG members.
Below we have an example of grouping Lots:
SubmissionResult situation
Creating an instance example for tender submission:
Should we represent parallel ranking or keep it at the level of Lot?
It is decided to keep T B G 1&2 outside of the model.
Business terms that indicate values
BT-161 and BT-118 are just computed data.
StatisticalInformation is only good after the contract has been awarded.
Discussion about epo:StatisticalInformation:
-
Replace TenderLot with Tender in all attributes: check epo:StatisticalInformation.
-
We need epo:StatisticalInformation at the Result Notice level and Lot level.
-
This information is published only in Result, DAP and Completion Notices.
DECISIONS:
-
LotGroup is defined in ProcedureTerm.
-
Tender is always submitted on a Lot (never on a LotGroup)
-
Tender may be subject to grouping by a LotGroup (at most one)
-
/!\ This means that we still need to think about how to represent the financial offer for a LotGroup in the context of a LotGroup Tender submission.
Working Group meeting
Date: 08/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Continue discussing the List of values.
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
Discussion
Business terms that indicate values
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings.
-
Renamed the relationship in BT-27 from epo:hasInitialEstimatedValue to the already existing one in the model, epo:hasEstimatedValue. This is because the predicate is attached to the Lot/Procedure it implies that it is the initial value and no temporal reference is necessary.
-
Rename epo:hasTotalFrameworkValue to epo:hasTotalFrameworkAgreementValue
-
All relationships to epo:MonetaryValue that contains the word “Framework” should be renamed so that we add “Agreement” as well.
-
Rename relationship for eForms BT-156, Group Framework Value, to epo:hasFrameworkAgreementValue.
-
Presenting the example for the lot award decision situation:
-
Proposing to have a ProcedureObject as a superclass for Lot and LotGroup:
-
We need to connect the LotGroup with some Term classes in the ePO model.
-
Presenting a new example of Tender Submission:
-
Presenting an example of the awarding:
Working Group meeting
Date: 01/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Tender was merged into TenderLot:
-
show the result
-
ask about “isSubjectTo” submission term
-
-
Continue discussing the List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
-
Discuss Documents diagram.
Discussion
Tender & TenderLot merging
-
There were two isSubjectTo relations:
-
epo:Tender epo:isSubjectTo epo:SubmissionTerm
-
epo:TenderDocument epo:isSubjectTo epo:SubmissionTerm
-
-
These two seem redundant after merging Tender with TenderLot.
-
The attributes from the SubmissionTerm class are mixed between Tender and Submission related attributes.
-
The guarantee and the electronic Signature are not at the Submission level.
-
We might need to create a TenderTerms class.
-
The bi-directional epo:attaches/epo:isAttachedIn relation between Tender and TenderDocument does not seem right as well.
-
A document may attach another document.
-
Removed any epo:attaches/epo:isAttachedIn relations from subclasses of epo:Document and create an unidirectional relation epo:attaches/epo:isAttachedTo at the epo:Document level.
-
Changing the definition for epo:Document with the following:
-
epo:RequestForClarification is on the EO side, but has nothing to do with the Tender (not a Tender Document).
This is a diagram for a future Application Profile:
-
The RequestForClarification, RequestForParticipation and ExpressionOfInterest are not generalisations of TenderDocument.
-
TenderDocument is no longer needed.
-
The association attaches / isAttachedTo should be replace by associatedWith.
-
The attaches predicate between Tender and ESPD response, Technical Offer and Financial Offer should be subproperties of associatedWith within any AP that will be created.
*Decisions: *
-
Investigate whether we need to create a TenderTerms class. (to distinguish between the action of submission and the content of submission)
Working Group meeting
Date: 22/02/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
What is the proper way to represent Lots & LotGroup and Tender/TenderLot & TenderLot group? Continue modelling the Tender/TenderLot example in the sandbox.
-
In deciding the above how do awarding, selection and exclusion criteria interplay in the case of Lots and LotGroups. This is important to understand how the TenderLots (and eventually TenderLotGroups) relate to the Lots.
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
Discussion
Lot and LotGroup
-
When (In which situations) LotGroup is relevant and when it is not?
-
Is the TenderLot relevant for competition/submission/evaluation only and it disappears in the contracts?
-
-
Does the LotGroup have its own award criteria or reuses those of the composing lots?
-
Is the LotGroup a subclass of Lot? They seem to share lots of attributes in common, and for this reason a common super-class would come in handy for good modelling. For example both of them may have FrameworkAgreementTerms, various criteria, estimatedValues, etc.
-
Then the same applies to TenderLotGroup, if such a class is necessary at all?
Page 11 of F2F-WGM 9th (from 14 of June 2019)
-
It was noted that the award criteria are not dependent upon a group of lots because the award criteria are applied before grouping the lots.
-
The Working Group had troubles understanding the Directive and the eForms concerning the Group of Lots value. It looks like the market could do synergies combining groups of lots but still the award criteria are set for the individual lots. An issue could be raised to eForms once the WG has clarified its findings especially concerning BG 330 Group award which seems to be in contradiction with recital 79 of Directive 2014/24/EU. It was also noted that the ontology covers scenarios that may not exist in all Member States.
Consequence for the model (?):
-
LotGroup is merely a grouping of lots, without many attributes of its own, or …
-
LotGroup is (almost) like a Lot, which overrides the properties of composing lots. For example, Lot "estimated values" will be overridden by the LotGroup values.
-
SelectionCriteria of a LotGroup can override (take precedence on the sum of the two) the SelectionCriteria of individual Lots or keep the SelectionCriteria of the individualLots.
-
LotGroup is a collection, it is not another type of Lot. It is a mechanism to group lots and differentiate selection criteria.
TenderLot and TenderLotGroup
-
What is the connection between TenderLots to Lots and Groups? Is there a better way of calling the TenderLot?
Current definitions:
-
TenderLot: Part of the tender that applies to the related lot. Additional Information: See also the definitions for Tender and Lot for a complete understanding. (apparently no longer needed)
-
Tender: Information submitted by the economic operator to specify its offer regarding one or more lots or the whole procedure, in response to the call for tender. (WG approval 07/11/2018)
-
The common part that is submitted, in the case of multiple submissions by the same tenderer, is moved elsewhere (i.e. ESPD response, which has to be submitted anyway each time including the exclusion ground) and therefore we no longer need this generalisation. Thus we can merge the Tender and TenderLot classes.
-
Decision: Investigate if/how we can delete the TenderLot class?
Decision: no need for TenderLotGroup.
Business terms that indicate values
-
List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings
Additional notes:
Presenting the instance example for tender with selection criterion.
With the new ESPD they have to reuse the same exclusion criteria for each TenderLot.
Exclusion Grounds are at the level of Procedure.
The financial and technical Award Criteria are to be set at the level of each Lot.
LotGroup can have the same kind of characteristics as Lots. The cardinalities are different.
One Lot has just one offer per each Selection Criteria.
A LotGroup can have its own Selection Criteria that overrides the SelectionCriteria for each of the Lots or keep the ones from each Lot.
AwardCriteria will be the same for LotGroup as the ones for each Lot.
We will need to go for a different granularity for ESPD in the case of FinancialOffer.
Award Criteria are actually questions.
The Financial Offer is per Lot.
Presenting a real world example of a tender at instance level.
Delivery example diagram
Competition diagram:
epo:hasEstimatedValue should be the same in all procurement phases.
-
Corrigendum: The estimated value might change only if a corrigendum notice is instantiated.
-
Should we accept to extend the definition of an object previously announced? (for example Lot) It’s a good practice that once an object is instantiated they should not be modified, but only referred to. (ex: Lot hasEstimatedValue and Lot hasAwardedValue; awarded value should not be a property of a lot but of something else)
Decision: Put all the BGs in the value type spreadsheet.
Working Group meeting
Date: 15/02/2022
Participants: Cecile Guasch, Giorgia Lodi, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Natalie Muric
Approved implemented changes
-
Rename epo:Value class to epo:MonetaryValue class.
-
Maximum and Minimum attributes were proposed to be used as predicates: epo:hasMinimumAmount and epo:hasMaximumAmount; and epo:hasOverallAmount.
-
Delete epo:Amount class and use epo:MonetaryValue class instead which has amount number and currency attributes.
-
The source of the relations epo:hasEstimatedUserConcessionRevenue and epo:hasEstimatedBuyerConcessionRevenue have been moved from epo:Lot to epo:TenderLot. This is in accordance with eForms Regulation (BT-160 and BT-162).
-
Attributes from epo:StatisticalInformation, epo:hasLowestReceivedTenderLotValues and epo:hasHighestReceivedTenderLotValues, become relations to epo:MonetaryValue. (BT-710 & BT-711)
-
Contract class has no value(s). This is in line with the eForms regulations. Note: It is the ContractTerm and Framework Agreement Term classes that may have specified monetary values. (BG-310 does not require value) Note: The contracts have values in some datasets (to be investigated which ones and to be decided at a later stage: e.g. tender lot awarded value becomes the contract awarded value).
-
Subcontract class is deleted because current forms and eForms do not require it.
Old model:
New model:
Discussion
Introduction of discussions last June on Monetary value and previous discussions on subcontract
Presenting how the sandbox implements Monetary value.
It is agreed with the WG the RevenueConcession concepts are transformed into predicates
Statistical information is looked at and the plurals are to be made into singular.
It is agreed to have a predicate hasHighestReceivedTenderlotValue from StatisiticalInformation to MonetaryValue (the same for LowestReceived….)
This was agreed as the Tender is specifically mentioned in the Notice.
It seems that Contract is not specifically mentioned in the eForms. It should be checked with DG GROW if this is because it can be implied from the TenderValue.
Discussion whether the aggregate of contract values in the notice should be considered in the ontology
It should be noted that the consumption of the Contract will need to be shown in future versions of the ontology.
In Italy:
HasEstimatedValue is in planning
HasMaximumValue is in the tendering
HasAwardedValue is in Awarding
Has MaximumEstimatedValue in Contract (not sure if correct)
This shows we should pay attention to situations, without meaning that process modelling is needed.
This is represented in the SubcontractingEstimate class that the WG accepts along with the removal of the subcontract class that can be reintroduced if a use case is provided at a later stage.
It is noted furthermore that the subcontract is not mentioned in the contract (though this should be confirmed by other MS).
Working Group meeting
Date: 08/02/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
-
We started grouping all classes from the ePO model, like in the image below:
-
Provide a narrative for all the packages in order to make it more understandable by the business people.
-
Short discussion regarding the documents diagram which was also discussed last time.
-
Kept only the top level of notices in the model: planning, competition, DAP, result, completion and contract modification.
-
Predicates epo:relatesToNotice and epo:relatedToNotice are from the 2.0.1 version:
-
Why not include them at the class level?
-
epo:refersToResultNotice is a specific type of the predicate epo:relatesToNotice? This can be deleted because this relation exists at the level of an epo:Notice class. But this has a different cardinality (mandatory 1) so we can keep it and use it for an AP of notices.
-
-
-
Discussion about the structure of phases in the Procurement domain.
-
Is it valuable to have a Result Notice or just a Contract Award Notice?
-
Mentioning that a Result Notice contains CAN general, CAN social and also design.
-
It is good to have this classification.
-
-
Showing the situation usage example for Winner BG:
-
If we decide that we don’t want to keep the Notice subclasses in the model, we should find a way to move the attributes from some of them.
-
Prepare a list with all the problems that we found while doing the mappings of the content to eForms notices. (publish a future agenda; maybe as a GH issue, with priority if possible.) == Working Group meeting
Date: 01/02/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Update HTML version of model-refactoring branch with new diagrams of documents and present them to the WGM.
Discussion
-
Do we have abstract classes or not? Because abstract classes are not instantiated, it is ok to have them since they won’t generate new URIs. Do we really need all these classes for the requirements (standard forms)?
-
Requirement:
-
It should cover eForms, and current forms if possible
-
It should cover notices, eOrdering and eCatalogue.
-
-
Nothing regarding the payment or submission in the data. Only regarding the result of these actions.
-
A request for providing some more information regarding the new proposed model was made.
-
Besides eForms and standard forms, there is some BDTI data from the Italian and Norwegian side.
-
We concentrate on stabilising this for eForms and Notices and then challenge the model to include some use cases that are not there.
-
There are some use cases where the roles are not defined that well.
-
We should find a small set of data that fit most of the use cases.
-
We don’t know yet if every info from the current forms can be mapped to eForms.
Notice core module
-
epo:hasLegalBasis is for the Procedure or for the Notice?
-
It is the content of the document that matters, so the Procedure should have a legal basis.
-
If we have this at the PRocedure level we could assure a robust approach.
-
There is an exception if we have only a PIN and not a Procedure, so we will talk about a project.
-
The fact that notice types belong to a legal basis is something that is part of the internal system that has to choose the notice type.
-
It is good to analyse which notice type is needed where but it is not needed to express the public procurement information.
-
Presenting the eForms mappings.
-
The mappings to the Notice content should not be part of the ePO. We are doing this low-level exercise to discover if the current model can express everything.
Questions:
-
If we have a project and it changes the legal basis in between what can we do?
-
What happens to fields that are not mandatory based on the country?
-
We should provide the best cardinalities in order to avoid this.
-
Documents hierarchy
-
It appears that the way Notices are currently defined are not directly mappable to the eForms or Standard Forms.
-
We advise to revise the level of granularity at which these concepts are defined.
-
For example, in eForms and Standard forms there are two types of ContractAwardNotice whereas in EPO only one.
-
More notice types are missing.
Discussion on PIN subclasses:
-
In the NoticeType PIN the acronym is used with two meanings:
-
Prior Information Notice
-
Periodic Indicative Notice
-
-
We shall be careful when each is used and modelled accordingly in Ontology.
-
In notice-type controlled vocabulary, the BuyerProfile is considered a PIN:
Discussion on CallForCompetition class:
-
In the current model this is a procurement document, but in notices it is a notice type.
-
epo:CompetitionNotice class is an epo:ProcurementDocument as well, and not epo:ClassForCompetition. === Questions:
-
Should epo:Notice be a subclass of epo:ProcurementDocument?
-
From the directive:
-
Call for competition is a procurement document.
-
Shouldn’t BuyerProfile be a subclass of PIN? == Working Group meeting
Date: 25/01/2022
Participants: Cecile Guasch, Giorgia Lodi, HK, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Present HTML version of model-refactoring branch and present Buyer role and Agents diagrams. Role dependencies included.
Discussion
On branch feature/model-refactoring we have a common model for both models.
The HTML format is on docs.ted.europa.eu[docs.ted.europa.eu]
In the eProcurement Ontology section we have the Working Group meetings. We provide the meeting minutes in two formats: one long text or meeting by meeting.
In the epo-docs section we have two versions of the documentation: dev and 2.0.0.
In the dev version we have the HTML reports based on models existing in various active branches.
We could create a 2.0.1 version and add the HTML report for the feature/frozen-2.0.1 branch.
The epo:Purpose class could be included in the procurement objects.
We will make sure to add diagrams that reflect the model properly.
Buyer Role diagram
The Procurement Service Provider Role can act on behalf of the Buyer. Both roles can be played by a Central Purchasing Body.
Central Purchasing Body should be a type of Role and not an Organisation.
epo:actsOnBehalfOf and epo:delegatesAncillaryActivitiesTo relations are now at the Role level, and not at the Organisation level like in the 2.0.1 version.
Based on the definition of the buyer role, the Buyer is a conflation of both Awarder and Acquirer.
By being so specific with the roles, we may add complexity to the model.
Checking the Open Contracting Data Standard: https://standard.open-contracting.org/1.1/en/schema/codelists/#party-role
If we specify just the Central Purchasing Body, it should be enough to cover all data.
Discussion based on the eForms codelists:
https://op.europa.eu/en/publication-detail/-/publication/73a78487-cc8b-11ea-adf7-01aa75ed71a1
Discuss the BuyerProfile class. It has only an attribute, epo:hasURL. We could add this attribute in the epo:Buyer class in order to simplify the model. We need to further discuss this issue in order to clarify.
Working Group meeting
Date: 18/01/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
A new branch from sept 2021 was created to host a frozen version of the ePO model at that time, including Reg2015 and BDTI AP modules. The later APs are removed from the dev version of ePO (master branch).
-
Present the DEV version of the ePO documentation.
-
Some epo:Indicator attributes are missing. We recommend adding the indicators where possible.
-
Document on explaining modelling roles
-
Finished implementing Subroles
-
Discuss indicator attributes:
-
The use case for BT - 634 Procurement Relaunched is the announcement that a Procedure should be relaunched.
-
An option is to add it to the Contract Award Notice phase.
-
Can we use epo:announcesToBeRelaunched instead of this?
-
This is related to epo:hasNonAwardJustification .
-
A procedure can be cancelled before Awarding.
-
-
New definition for epo:hasAdditionalNonAwardJustification attribute on epo:LotAwardDecisionSituation class:
“Further justification for the non award.
Additional Information:
This is generally used when the non award reason code is set to “Other”.
WG 18/01/2022”
-
The procurement process is per Lot.
-
epo:announcesProcedureWillBeRelaunched relations were added from epo:ContractAwardNotice to epo:Procedure and epo:Lot in order to map BT-634.
-
At the Procedure level we created a relation epo:isProcedureToBeRelaunched attribute as epo:Indicator on the epo:ContractAwardNotice class.
-
At the Lot level we created a relation epo:announcesCancelledLotToBeRelaunched between epo:ContractAwardNotice and epo:Lot.
-
Added a new definition for epo:isProcedureToBeRelaunched: “Indicates whether a whole procedure or only a part of it shall be relaunched.
Additional Information:
If it’s True it means either the Procedure or Lot shall be relaunched.
This indicator should be used in tandem with the relation announcesCancelledLotToBeRelaunched if it concerns one or more lots.
If, however, no link to the lots is specified, then it indicates that the whole procedure shall be relaunched.
WG approval 18/01/2022”
Composition & specification relations between Procedure and Lot
-
We recommend using composition type of relation between Procedure and Lot and delete specification relations.
-
Changed epo:isComposedOf to epo:hasComponent.
-
Procedure does not exist without Lots.
Inclusion relation between Tender and TenderLot
-
A Tender does not exist without TenderLots.
-
Changed the inclusion relation between Tender and TenderLots to a composition. === Subroles implementation
The subroles were initially modelled as relations from Buyer and Reviewer role classes to Lot class. All these relations have been reified into either Terms or Situations, i.e. deleted and the appropriate relational class created or augmented.
Working Group meeting
Date: 11/01/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costetchi
Note editor: Andreea Pasăre
Agenda:
-
Extension management methodology (for CEN needed soon)
-
Need for having notices published in RDF format in Cellar
-
Discussion regarding at-voc:nuts and other options that can be used instead
-
Document on explaining modelling roles
-
Core Location alignment - go through the open issues labelled Location and close where possible
-
GitHub structure presentation - branches & documents
Extension management methodology
-
In CEN working will be discussed process models, needing to refer to the EPO.
-
Extension of EPO (as APs or models) with specific attributes and relations is foreseen.
-
Potential issue: redundant extension; therefore EPO governance is needed.
-
Need: asset governance formalisation for EPO.
-
Guidance document needed before Q2.
Core location implementation
Agents diagram:
-
epo:Location has been removed
-
epo:Address has been changed to locn:Address (with specific attributes and definitions)
-
All predicates from epo classes to epo:Location were moved to locn:Address and renamed to epo:hasAddress and epo:hasRegisteredAddress
Competition diagram:
-
Replaced epo:LocationCoordinate with dct:Location (with specific attributes and definitions)
-
Added locn:Geometry class (with specific attributes and definitions)
Discussion:
-
epo:hasLocationCoordinate should be deleted
-
locn:Address should be linked to locn:Geometry
-
Should we move epo:hasOpeningPlace to dct:Location? Double check if epo:OpeningTerm is a spatial object
-
It seems that epo:Location class was not removed; it should be removed
-
In eForms we use L3 NUTS code, but if we align to core location they provide locn:adminUnitL1 and locn:adminUnitL2
-
Should we consider INSPIRE instead of Core Location or ask Core Location to make changes in order to be more flexible
-
Should locn:adminUnitL1 link to at-voc:country instead of at-voc:nuts?
-
What can we do with locn:adminUnitL2? Keep it linked to at-voc:nuts.
-
We miss level 3 of at-voc:nuts. We could add a predicate for L3.
-
Ask Core Location for details on how we can go to L3 NUTS.
-
Change the model to the following diagram and test it with real data.
GitHub structure - branches & documents:
-
Renamed branches to better reflect the development:
-
feature/sandbox-roles
-
feature/notice-systematisation
-
feature/model-refactoring
-
-
Generated HTML reports for master branch and model-refactoring branch; added them to epo-docs repository in order to be displayed on https://docs.ted.europa.eu/
-
Created automated owl generation when publishing on master, along with a conformance check.
Discussion:
-
Delete the sandbox folder from master branch.